Method and apparatus for configuring systems

ABSTRACT

The present invention employs a generative approach for configuring systems such that a system may be configured based on component or resource requests, or input in the form of need. The present invention provides a constraint-based configuration system using a structural model hierarchy. The structural aspects of the model provide the ability to define a model element as being contained in, or by, another model element. In addition, the structural model provides the ability to identify logical datatype and physical interconnections between elements and establish connections between elements. To configure a system, the present invention accepts input in the form of requests (e.g., component or resource) or needs, such as an expression of a need for a desktop computer system to be used in a CAD (i.e., computer-aided design) environment. Using this information, the present invention configures a system by identifying the resource and component needs, constraints imposed on or by the resources or components identified, and the structural aspects of the system.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of computer-based systemconfiguration.

2. Background Art

Configuring a system refers to the process of selecting and connectingcomponents to satisfy a particular need or request. If a system is basedon a limited number of components, the process of configuring the systemcan be relatively straightforward. For example, the purchase of anautomobile requires a salesperson to configure a system (automobile andassorted options) to satisfy a customer's request. After selecting froma plurality of models, the salesperson completes the transaction byselecting options to configure and price an automobile. The configuringof such a simple system can be accomplished with a pencil and paper.

As system specifications become more customized and varied,configuration alternatives increase and the task of configuring a systembecomes more complex. This increased complexity has resulted in a needfor computer-based assistance with the configuration process. Earlycomputer-based systems expand independently-generated configurationorders for systems into manufacturing orders. They do not address theactual need for computer-based tools prior to the order expansion. Thatis, they do not address the actual generation of a system configurationbased on needs and/or request input.

An example of a complex system is a desktop computer system. Theavailable configuration alternatives of a computer system are numerousand varied, including alternatives available when choosing themicroprocessor, motherboard, monitor, video controller, memory chips,power supply, storage devices, storage device controllers, modems, andsoftware.

Configuring a desktop computer system requires that a selected componentis compatible with the other components in the configured system. Forexample, a power supply must be sufficient to supply power to all of thecomponents of the system. In addition, the monitor must be compatiblewith the video controller (e.g., resolution), and the storage devicemust be compatible with its controller (e.g., SCSI interface). Amotherboard must have enough slots to handle all of the boards installedin the system.

The physical constraints of the cabinent that houses the system'scomponents are also considered. The cabinet has a fixed number of baysavailable for storage devices (e.g., floppy disk drives, hard diskdrives, or tape backup units). These bays have additional attributesthat further define their use. For example, the bay may be located inthe front of the cabinent and provide access from the front of thecabinet. Another bay may be located behind the front-accessible bays,and be limited to devices that do not need to be accessed (e.g., harddisk drive). Bays may be full-height or half-height. Before a storagedevice can be added to the configuration, a configuration system mustidentify a bay into which the storage device will be housed. Thisrequires that at least the accessibility and height of the storagedevice must be examined to determine compatibility with an availablecabinet bay.

The connection between a storage device and its controller must bedetermined based on the location of each. The cable that connects thestorage device and its controller must provide compatible physicalinterfaces (e.g., 24-pin male to a 24-pin female).

A method of establishing a communication pathway in a computer system isknown as daisy chaining. Daisy chaining provides the ability tointerconnect components such that the signal passes through onecomponent to the next. Determining whether a daisy chain may beestablished requires that the available logical (e.g., IDE or SCSI) andphysical interfaces (e.g., 24-pin) of all elements in a daisy chain beknown. In addition, it is important to know whether conversions from thesource datatype to the destination datatype are allowed. When a daisychaining candidate is added to the system, the interconnections andconversions between existing components may be checked to determinewhether the new component should be an element of the daisy chain.

The power supply and storage device component examples illustrate theneed to define the structural interrelationships between components(i.e., physical and spatial relationships). To further illustrate thisnotion, consider placing components requiring electrical power such ascomputer, telecommunication, medical or consumer electronic componentsinto two cabinets. Further, each cabinet has an associated power supplythat supplies electrical power to the components inside the associatedcabinet. To account for electrical power consumption and the requirementthat no power supply is overloaded, the model must comprehend thespecific cabinet in which each component is placed and update theconsumed power for each cabinet. While the total power available in thetwo cabinets may be sufficient for all of the components to be placed inboth of the cabinets, a component cannot be included in a cabinet if itsinclusion would cause the cabinet's power supply to overload. Therefore,the physical placement of the component in a cabinet must be known tomake a determination if the subsequent placement of a component isvalid. Similarly, any physical connections between these components mustbe taken into account. Each component's position in the structuralhierarchy is used to determine minimal or optimal lengths for theconnecting components.

Early computer-based configuration systems employed an approach referredto as the rule-based approach. Rule-based configuration systems definerules (i.e., “if A, then B”) to validate a selection of configurationalternatives. Digital Equipment Corporation's system, called R1/XCON(described in McDermott, John, “R1: A Rule-Based Configurer of ComputerSystems”, Artificial Intelligence 19, (1982), pp. 39-88) is an exampleof a rule-based configuration system. R1/XCON evaluates an existingindependently-generated system order and identifies any requiredmodifications to the system to satisfy the model's configuration rules.The rules used to perform the configuration and validation processes arenumerous, interwoven, and interdependent. Before any modification can bemade to these rules, the spider's web created by these rules must beunderstood. Any changes to these rules must be made by an individualthat is experienced and knowledgeable regarding the effect that anymodifications will have to the entire set of rules. Therefore, it isdifficult and time-consuming to maintain these rules.

A possible solution to the problems associated with rule-based systemsis a constraint-based system. A constraint-based system placesconstraints on the use of a component in a configuration. For example, ahard disk drive cannot be added to the configuration unless a compatiblestorage device controller is available for use by the request storagedevice. The requirement of a controller is a “constraint” on the harddisk drive.

While existing constraint-based systems address some of the shortcomingsof rule-based systems, they do not provide a complete configurationtool. Pure constraint-solving systems do not employ a generativeapproach to configuration (i.e., they do not generate a systemconfiguration based on needs, component requests, and/or resourcerequests). Existing constraint-based systems use a functional hierarchythat does not address structural aspects associated with the physicalplacement of a component in a configuration (e.g., memory chip onmotherboard or memory expansion board, storage device in cabinet bay, orcontroller in motherboard slot).

Bennett et al., U.S. Letters Patent No. 4,591,983 provides an example ofa constraint-based system that employs a recognition or verificationapproach to system configuration instead of a generative approach. Thatis, Bennett merely validates an independently-configured system. Inessence, an order is generated by an independent source such as asalesperson, and Bennett is used to verify that the system contained inthe order does not violate any constraints. Bennett does not generate asystem configuration based on needs or component requests (i.e., agenerative approach). Thus, Bennett does not provide the capability tointeractively configure a system by interactively selecting itscomponents.

A model consists of all of the elements that may be included in aconfigured system. In Bennett, the model elements are grouped into anaggregation hierarchy. An aggregation hierarchy creates hierarchicallevels that represent a group of elements. Branches from one entry inthe current level expand the entry, and the entry is “composed of” theelements in the lower level branches. For example, a desktop computersystem is “composed of” a keyboard, a monitor, and a system box. Asystem box is “composed of” a power supply, motherboard, cards, andstorage devices. The “composed of” relationship merely describes theelements that comprise another element. However, the “composed of”relationship does not define the structural relationships between themodel elements. The “composed of” relationship does not describe thephysical, structural relationships among the elements such as“physically contained inside,” “physically subordinate part of,” and“physically connected to.” Using the desktop computer system previouslydescribed, it cannot be determined whether or not a monitor is“physically contained inside” a desktop computer system. A system box is“composed of” storage devices, however it cannot be determined whetherone or more of the storage devices are “physically contained inside” thesystem box.

A functional hierarchy organizes the components of a model based on thepurpose or function performed by the components in the model. Each entryin the hierarchy can be further broken down into more specificfunctional entries. Thus, an entry's parentage defines itsfunctionality, and progression from one level to the next particularizesthe functionality of a hierarchy entry.

As used in current configuration systems, a functional hierarchy doesnot define the structural interrelationships or the physical and spatialinterconnections among elements. A functional hierarchy cannot place astorage device in a cabinet bay, a controller card in a particular sloton the motherboard, or a memory chip in a slot on the memory expansionboard.

FIG. 2 illustrates an example of a functional hierarchy.HardwareComponent 30 is the root element of the hierarchy. The nextlevel below HardwareComponent 30 (i.e., the second level 49) identifiesgeneral functions in the model. For example, ROM 31, Processor Unit 31,Processor 32, Memory 34, Cage 35, Board 36, Connector 37, and StorageDevice 38 all perform the function of Hardware Component 30 in additionto their own specialized functions. Processor 33 can be specialized tothe function of a SpecialPurpose 40 or GeneralPurpose 41. SpecialPurpose40 can be specialized to ArithmeticProcessor 51.

Referring to FIG. 2, it can be seer that a functional hierarchy does notprovide the ability to define the structural aspects of the system. Forexample, there is no capability to determine the contents of Cage 35.The physical and spatial location of MotherBoardSlot 54 descending fromSlot 46, in turn descending from Connector 37 cannot be determined fromthe functional hierarchy. There is no way of determining thatMotherBoardSlot 54 is contained by the motherboard. It is not clear fromthe functional hierarchy definition whether ArithmeticProcessor 51 islocated on the MotherBoard 44 or another model element. It cannot bedetermined whether MemoryChip 42 and ROM 31 are located on MotherBoard44, MemoryBoard 52, or another model element.

A functional hierarchy does not provide the ability to define actualinterconnections between configured instances or the data transfer. Thatis, that one component is connected to another with compatible logicaldatatypes (e.g., serial interface) and compatible physicalinterconnections (e.g., 24 pin). A functional hierarchy only defines thefunction that a component performs.

Because it does not define the actual connections between the componentsselected for a configuration, it cannot establish a daisy chain betweenconfigured components. Referring to FIG. 2, a functional hierarchydefines Connector 37, Storage Device Controller 53, Floppy Drive 48, andHard Drive 49 as types of components. To conserve resources, a user maywish to configure a system such that an occurrence of Floppy Drive 48 isdaisy chained to an occurrence of Storage Device Controller 53 throughHard Drive 49. However, the functional hierarchy can only reflect thatfact that a configured system may contain the functionality provided byStorage Device Controller 53, Hard Drive 49, and Floppy Drive 48. Itcannot reflect the fact that an occurrence of Floppy Drive 48 isconnected to an occurrence of Storage Device Controller 53 through anoccurrence of Hard Drive 49.

Therefore, a functional hierarchy can not traverse a connection pathwayto identify structural interrelationships among configured instances.Thus, a functional hierarchy cannot establish a daisy chain. Therefore,a functional hierarchy can not provide the ability to daisy chaincomponents.

Another example of a constraint-based system using a functionalhierarchy is provided in the following articles: Mittal and Frayman,“Towards a Generic Model of the Configuration Task,” in Proceedings ofthe Ninth IJCAI (IJCAI-89), pp. 1395-1401; and Frayman and Mittal,“COSSACK: A Constraints-Based Expert System for Configuration Tasks,” inSriram and Adey, Knowledge-Based Expert Systems in Engineering: Planningand Design, September 1987, pp. 143-66.

The Cossack system employs a functional hierarchy-based configurationsystem. According to Cossack, a system using a functional hierarchy mustidentify a configured system's required functions. Once the requiredfunctions are identified, Cossack must identify some particularcomponent, or components, that are crucial, or key, to theimplementation of these required functions. The Cossack representationdoes not make structure explicit. Further, Cossack does not providemechanisms for reasoning about or with structural information.Therefore, Cossack cannot make any structure-based inferences. Forexample, the internal data transfer paths within components are notrepresented. Therefore, there is no ability to trace data transferwithin a component, and no ability to establish a data connection withanother element.

A configuration system, whether used to configure a computer system orother system, should provide a tool to interactively: define andmaintain a model; define and maintain (i.e., upgrade) a configuredsystem; generate marketing bundles; generate a graphic representation ofthe physical and spatial locations of the components of the configuredsystem; use the graphic representation to modify or upgrade a configuredsystem; and generate configuration reports (e.g., failed requests,quotations, and bill of materials). Such a system must define thecomponents of a system, the structural relationships among thecomponents (i.e., spatial and physical locations), the actual physicaland spatial interconnections of the components, and the constraintsimposed by each component.

SUMMARY OF THE INVENTION

The present invention employs a generative approach for configuringsystems such that a system may be configured based on component orresource requests, or input in the form of need. The present inventionprovides a constraint-based configuration system using a functionalhierarchy that comprehends hierarchical and non-hierarchical structure,and associated constraints that can reason about and generate structuralrelationships. The structural aspects of the model provide the abilityto define a model element as being contained in, or by, another modelelement. In addition, the structural model provides the ability toidentify logical datatype and physical interconnections between elementsand establish connections between elements.

To configure a system, the present invention accepts input in the formof requests (e.g., component or resource) or needs, such as anexpression of a need for a desktop computer system to be used in a CAD(i.e., computer-aided design) environment. Using this information, thepresent invention configures a system by identifying the resource andcomponent needs, constraints imposed on or by the resources orcomponents identified, and the structural aspects of the system.

The system configuration can be based on a general definition of asystem (i.e., desktop computer system to operate in a CAD environment),or at any level of increased specificity (e.g., disk drive bymanufacturer and model number). The system configuration can be based onspecific component requests (e.g., laser printer), or by need (e.g.,printing capability). Once the system is configured, the configuredsystem can be bundled into products, and a quote can be generated. Thebundling process may include the specification of heuristics to controlthe product-to-component mapping. For example, the product that coversthe largest number of components can be selected over other possibleproduct selections that cover a lesser amount of components.

The functional, structural hierarchy of the present invention providesthe ability to define the structure of the configuration model and thesystems configured from the model. The structural hierarchy includes acontainer structure. A container provides the ability to specify thatone component is contained by, or in, another component. Thus, it ispossible, for example, to identify that a component request for a diskdrive cannot be satisfied because there are no empty cabinet bays in thecabinent specified to contain the component requested.

The structure hierarchy notion provides the ability to pool resources.Explicity representation of structure, specifically hierarchicalstructure, provides the ability to define and access inheritedresources. For example, computer, telecommunication, medical, orconsumer electronic components can be placed in a cabinet that providespower to those components. These individual components can inherit theelectrical power resource from a structural superior (i.e., ahierarchical entry that resides one or more levels above the componentsin the model hierarchy). Further, the structural superior can poolresources and provide an homogeneous resource to its structuralinferiors (i.e., a hierarchical entry that resides one or more levelsbelow the structural superior in the model hierarchy). For example, acabinet might contain more than one electrical power source, however,the resource is presented to structurally inferior components as asingle resource pool. Thus, if a component requires a particularresource, this resource can be supplied by a resource pool. For example,if a desktop computer system's cabinet contains multiple power supplies,a disk drive component may draw from resource pool without any knowledgethat the resource need is satisfied by multiple power sources.

In addition, the structural specification provides the ability tospecify the connections between components of a configured system. Ascomponents are added to a configuration, the physical and logicalinterconnections; that are required to assemble the system componentsmay be verified. For example, before adding a printer with a seriallogical connection and a 24 pin physical connection to theconfiguration, a serial port must be available in the configured system.In addition, a physical connection must be made between the printer anda serial port. If the serial port is a 9-pin female physical connectionand the printer has a 24-pin female connection, a cable must beavailable to physically connect the printer and the serial port. Inaddition, the actual connection is created in the configuration and canbe examined in subsequent connection processing. Connection processingprovided the ability to identify any criteria for satisfying aconnection request. For example, connection criteria may include thecheapeast, longest, or optimal throughput connection.

Connection processing may also be used to optimize the use of theconfigured system's resources. For example, a controller's resources canbe optimized by daisy chaining other components together. By connectingone component to another via multiple intervening components, multiplecomponents may be connected to a single component via a single port orconnection.

In the present invention, a modeling language is used to define a modelhierarchy. The model hierarchy is structural and functional. Themodeling language provides the ability to define a Product Base that maybe grouped into Product Lines. The structural hierarchy model includesthe Component, Composite, Container, Port, and Connector base classes.These base classes may branch into derived classes (i.e.,system-specific classes) and terminate at leaf-descendants.Leaf-descendants define the type of components in the functional,structural hierarchy model. Attributes, datatypes, resources, andconstraints further define the model.

A model language provides the format for defining the elements, theconstraints placed on the elements, and the structure of the model. Themodel language may be used directly, or generated based on input from aninteractive model maintenance system used to facilitate the creation andmaintenance of the model.

The maintenance system graphically displays the model, and provides theinterface for the selection of model elements to be updated. Once thedesired updates have been made, the maintenance system provides theability to test the new model, or verify that the new model can besuccessfully compiled.

Once a model has been successfully defined, the present inventionprovides the ability to configure a system using the functional,structural hierarchical model. An interactive interface provides theability to express a configuration in terms of a model element (i.e.,components) request, resource request, and/or needs (i.e., requirements)request. A configuration engine is invoked to satisfy these requests.

The configuration engine accesses the Product Base to satisfy therequests in a defined priority. A request is processed by addingcomponents to the configuration, or identifying existing components thatcan satisfy the request. Further, the interconnections, data transferpathways, and dynamically-determined structural relationships aredefined. When a request is successfully processed, the configurationmodifications are “committed.” Failed requests are reported.

A graphical depiction illustrates the configured system and itsstructural characteristics. The elements of the configured system areillustrated in terms of their physical and spatial location relative toother elements. Elements are contained in other elements, comprised ofother elements, or connected to each other. This graphical depictionfurther provides an interface to modify and maintain elements of theconfigured system.

The configured system's elements are bundled into available marketingand manufacturing packages for system quotation and manufacturingpurposes. The bundling process performs a product-component mappingbased on product definitions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the configuration computer system.

FIG. 2 illustrates a functional hierarchy.

FIG. 3 illustrates the functional, structural hierarchy comprised of thefive base classes, derived classes, and component types.

FIG. 4 is the functional, structural hierarchy for a model to configurecomputer systems.

FIG. 5 illustrates component interconnections with multiple interveningcomponents and data types.

FIG. 6 illustrates the Configuration Engine process flow.

FIG. 7 illustrates the SatisfyResourceRequest process flow.

FIG. 8 illustrates the SatisfyContainerConstraint andSatisfyComponentConstraint process flow.

FIG. 9A illustrates the SatisfyConnectionConstraint process flow.

FIG. 9B illustrates the CandidatePorts process flow.

FIG. 10 illustrates the EstablishSetCover process flow.

FIG. 11 illustrates a system window for a desktop computer systemconfiguration.

FIG. 12 is flow diagram illustrating the functional operation of theConfiguration System.

DETAILED DESCRIPTION OF THE INVENTION

A method and apparatus for configuring systems is described. In thefollowing description, numerous specific details are set forth in orderto provide a more thorough description of the present invention. It willbe apparent, however, to one skilled in the art, that the presentinvention may be practiced without these specific details. In otherinstances, well-known features have not been described in detail so asnot to obscure the invention.

The present invention provides a tool for configuring systems that hasapplication to a wide range of domains including the following: computerhardware, computer software, computer networks, telecommunicationsystems (e.g., PBX and voice mail), copiers, medical imaging systems,vehicles (e.g., fire trucks and construction equipment), electroniccontrol systems, buildings, modular furniture, manufacturing equipment,manufacturing systems, consumer electronic equipment, and electronicsystems.

FIG. 1 is block diagram of the configuration system of this invention.The configuration system 10 is comprised of the Model MaintenanceSubsystem 12, the Configuration Generation and Reporting Subsystem 14,the Bundling/Quotation Subsystem, Communications Bus 18, Input/Output20, Memory 22, Central Processing Unit 24, and Mass Storage 26.

FIG. 12 is flow diagram illustrating the functional operation of theConfiguration System. At block 600, a model base is read. TheConfiguration System uses a model base that contains information aboutall of the elements available to configure a system (e.g., componentsand resources) This model base is referred to as a Product Base.

A model language is used to create the Product Base. The model languageprovides the syntax, or statements, used to define the model elements,the constraints placed on the model elements, and the structure of themodel. At processing block 604, the model definition can be enteredusing the model language and model definition processing is ended at606.

Model Maintenance—The process of defining a model can be facilitated ifthe Model Maintenace Subsystem is chosen at decision block 602 (i.e.,“use Model Maintenance Subsystem?”). At block 608, the model, either newor existing, is displayed. At block 610, the model can be edited. TheModel Maintenance Subsystem 12 provides the ability to test the validityof and debug the modified model at decision block 612 (i.e., “writeintegrity, ProductBase integrity, or Debugger?”). A “write integrity”selection determines the integrity of the parse file (i.e., subsets ofthe Product Base) with the addition of the modifications. a “ProductBaseintegrity” selection determines the integrity of the Product Base withthe addition of the modifications.

If the “Debugger” is chosen, benchmark system configuration requests areread from a file at block 618. At block 14, the Configuration Generationand Report System 14 is invoked to configure a system using the modifiedmodel and the benchmark configuration requests. A trace of theprocessing of these requests by the Configuration Generation andReporting System 14 may be made to examine the configuration process.

If there are additional modifications to the model at decision block 622(i.e., “modify model?”), a graphic representation of the model isdisplayed at 608, and the modfication process continues at block 610. Ifthere are no other modifications, the model definition is generated atblock 624, and the Model Maintenance Subsystem ends at block 606.

Configuration and Reporting System—The Configuration and ReportingSystem 14 uses the model definition to generate a system configuredaccording to the user-specified requests and needs. The resultingconfiguration is graphically depicted. Reports are generated to provideinformation regarding the configuration. If it is determined that anexisting configuration is being upgraded at decision block 630 (i.e.,“upgrading existing system?”), the existing system is read and itselements marked as existing in block 632. If a new system is beingconfigured, a blank system instance is created at block 634. The formsused to input element requests or needs is displayed at 636. If input isnot complete at decision block 638 9i.e., “requests completed?”),processing continues it block 636.

Configuration Engine—Once all of the request and need input iscompleted, ConfigurationEngine is invoked to generate a configuredsystem based on the input at 640. A graphical representation of theconfiguration is displayed at 642. The configuration may be modified,reports may be generated, or the components of the configuration may bebundled and a quotation generated. If modifications are intended atdecision block 644 (i.e., “configuration modification?”), processingcontinues at decision block 652 (i.e., “filter model?”). If a filteredmodel is chosen at decision block 652, a subset of the model isgenerated at block 654. The model subset includes those model elementsthat can be selected given the current configuration. Processingcontinues at 636 to display input forms. If a filtered model is notused, processing continues at 636.

After a system is configured, the elements of the configuration can bebundled into marketing, or manufacturing, products. Bundler 660 maps theconfiguration components to products. Quoter 662 generates a costquotation for the configured system. At 664, the quotation is displayed.If there are no configuration modifications at decision block 666 (i.e.,“configuration modification?”), processing ends at 606. If there aremodifications to the configuation, the Configuration Generation andReporting Subsystem 14 is invoked at block 668.

Structural Hierarchy

The Configuration System of the present invention is a constraint-basedscheme using a functional, structural hierarchy. FIG. 3 illustrates thefunctional, structural hierarchy and five intrinsic base classes. Thefunctional, structural hierarchy contains a class hierarchy comprised offive intrinsic base classes 70 that define the basic types of modelobjects. These five base classes are: Component 60, Composite 62,Connector 64, Container 66, and Port 68. The Component 62 is the baseclass from which all other classes and component types are derived. FromComponent 62, each branch of the hierarchical tree begins with anintrinsic base class and branches into system-specific classes calledderived classes 88. Derived classes 88 are definitions of broadcomponent categories, such as storage devices, power supplies, andperipheral cards. Multiple generations of derived classes can descendfrom the base classes. Each branch terminates with “leaf descendants,”or Component Types 90. Component Types 90, represent actual componentsthat can be instantiated and configured.

The Composite class 62 is a static structure (i.e., elements that havesubstructure). Elements in this class have, or are, subcomponents of acomposition. The Connector class 64 branches from the Composite class62. This class defines the model elements that connect elements. Anelement in the Container class 66 indicates that the element may containother elements. Elements in the Port class 68 provide the portalternatives and define a port's datatype. Elements derived from thePort class 68 can be physically connected with other components derivedfrom the Port class 68.

The present invention provides the ability to represent within astructural hierarchy how components of a particular system existspatially and physically. Within the structural hierarchy, there arethree type of substructures: composite hierarchies, containerhierarchies, and port relationships. Composite hierarchies identifycomponents as part of other components. For example, a chassis has eightcard slots. Container hierarchies identify components as being containedin other components. A Container hierarchy is a dynamic structure inthat the structure is dynamically created when a configuration isgenerated. For example, a CPU card is placed in slot 0 of the chassis).Port relationships identify components that connect to other components.A connection, or port, relationship is dynamically created when aconfiguration is generated The relationships between generations withinthese substructures are expressed by the keywords “childOf,”“containedBy,” and “connectsWith.”

The “childOf” keyword indicates that a component is part of a componentthat is descended from class Composite. The “containedBy” keywordindicates that a component is contained within a component that isdescended from the Container base class. The “connectsWith” keywordindicates that a component connects to a component that is descendedfrom the Port Class.

Container hierarchies typically exhibit an alternating relationship withComposite hierarchies. That is, a container is often a “childOf” acomposite component, and the composite component is “containedBy”another container. Each substructure type has a root member that is alsoa descendant of the base class of the same name (i.e., Composite,Container, or Port). Members of a substructure can be of any classdefined in the Class Hierarchy. For example, a component of class bay,descended from Container Class might contain a component of classstorage-device (descended from Component Class) or of class card_chassis(descended from Container Class).

FIG. 4 illustrates a structural hierarchy with the five base classes,derived classes, leaf descendants, and substructure relationships. Thestructural relationships further define the structural aspects of themodel. For example, Slot 114 is a “childOf” Cabinet 110. Therefore, Slot110 is a subcomponent of the composite component, Cabinet 110. Further,Cabinet 110 is a “ChildOf” System 116. Second occurrences of Card 118(i.e., 118A) and Slot (i.e., 114A) illustrate the substructuralrelationship between Card and Slot. Card 118A is “containedBy” Slot114A. Similarly, StorageDevice 120A is “containedBy” Bay 122A, andDB25MaleDeviceOut 124A “connectsWith” DB25FemaleDeviceOut 126.

The structural aspects of the present inventions's model provides theability to inherit and pool resources. For example, a containercomponent, Cabinet, may consist of a chassis and two one-hundred wattpower supplies, A and B. Each of the elements within the chassiscontainer consume, or require some amount of power. If the chassiscomponent contains two central processing units (CPUs) that togetherconsume one-hundred and ten watts (e.g., fifty-five watts each), randomaccess memory that consumes seventy watts, and multiple cards (e.g.,controllers) that consume a total of twenty watts, neither of the powersupplies independent of the other could supply sufficient power to thechassis and its elements.

However, because the two power supplies are contained in, and are a partof, the Cabinet container, the two power supplies can be pooled togetherto supply the elements within Cabinet. Therefore, when the resourcerequisitions are being processed for the elements in this example, oneor the other may be used to satisfy the request. In addition, it ispossible to satisfy the resource need for any one of the elements byusing both power supplies. For example, if one CPU's resource needs areprocessed first using fifty-five watts of power supply A, and theresource processing for the RAM is processed next, the resource needs ofthe RAM maynot be satisfied by power supply A alone. However, it ispossible to satisfy the RAM's resource needs by using 45 watts frompower supply A and twenty-five from power supply B. Another resourcethat may use this resource pooling capability is a heat dissipationresource.

Containers

The structural hierarchy provides the ability to structure the modelsuch that one model element, or group of model elements, may becontained by another. The use of the contained model element in aconfiguration will be constrained by the availability of a containermodel element in the configuration.

FIG. 8 illustrates the SatisfyContainerConstraint andSatisfyComponentConstraint process flow. At decision block 500 (i.e.,“required instance already available in configuration?”), if therequired instance exists and is available to satisfy the constraint, theconstraint is satisfied by this available instance and processingreturns at block 526. If not, the required instance is instantiated, andthe Modifications List is updated at processing block 502. At decisionblock 504 (i.e., “any constraints to be processed?”), if there are noconstraints on the new instance, the constraint is satisfied by the newinstance, and processing returns at block 526.

If there are constraints to be processed, the next constraint isidentified at block 508. If it is determined that it is arequiresContainer constraint at decision block 510 (i.e.,“requiresContainer?”), processing continues at processing block 512(i.e., “satisfyContainerConstraint”) to satisfy the requiresContainerconstraint, and processing continues at decision block 522 (i.e.,“constraint satisfied?”).

If it is determined that it is not a requiresContainer constraint atdecision block 510, but it is determined that it is a requiresConnectionconstraint at decision block 514 (i.e., “requiresConnection?”),processing continues at processing block 516 (i.e.,“satisfyConnectionConstraint”) to satisfy the requiresConnectionconstraint, and processing continues at decision block 522 (i.e.,“constraint satisfied?”).

If it is not a requiresContainer constraint at decision block 510 andnot a requiresConnection constraint at decision block 514 (i.e.,“requiresConnection?”), processing continues at decision block 518(i.e., requiresComponent?”). If it is determined that it is arequiresComponent constraint at decision block 518 (i.e.,“requiresComponent?”), processing continues at processing block 520(i.e., “satisfyComponentConstraint”) to satisfy the requiresComponentconstraint, and processing continues at decision block 522 (i.e.,“constraint satisfied?”). At decision block 522 (i.e., “constraintsatisfied?”), if the constraint was satisfied, processing continues atdecision block 504 (i.e., “any constraints to be processed?”). If theconstraint was not satisfied, the constraint is marked as not beingsatisfied by an existing instance or the new instance, and the newinstance is removed from the Modifications List at processing block 524.Processing returns at block 526.

Connection Processing

The use of a model element in a configuration may also be constrained bythe ability to establish a connection to another model element. TherequiresConnection constraint requires that a physical connection existbetween two components. FIG. 9A illustrates the process flow forsatisfying the requiresConnection constraint. At processing block 280, atarget component is selected and a list of ports is created. Atprocessing block 282, the requested resources are allocated. Atprocessing block 284, CandidatePorts(list) is invoked to identifyunconnected ports that are accessible from the target component. Atprocessing block 286, candidate local ports (i.e., those ports that areunconnected and have the appropriate datatype) are identified. Atprocessing block 288, candidate connectors are identified.

At decision block 290 (i.e., have all connectors been tested?”), if allof the connectors have been tested, the request is marked as failed, andprocessing continues at block 306 (i.e., “return”). If not, the nextconnector is selected at block 294. At decision block 296 (i.e., “canphysical type of connector's port1 connect with physical type of targetport?”), if port1 of the connector is not the same physical type (e.g.,25 pin) as the target port's physical type, processing continues atdecision block 290 (i.e., “have all connectors been tested?”).

Otherwise, processing continues at decision block 298. At decision block298 (i.e., “can physical type of connector's port2 connect with physicaltype of local port?”), if port2 of the connector is not the samephysical type (e.g., 25 pin) as the local port's physical type,processing continues at decision block 290 (i.e., “have all connectorsbeen tested?”). Otherwise, processing continues at decision block 300.At decision block 300 (i.e., “does a transfer path exist between port1and port2?”), if a transfer path does not exist between port1 and port2,processing continues at decision block 290 (i.e., “have all connectorsbeen tested?”). Otherwise, the requested resource is allocated at block302. At processing block 304, the target port is connected to theconnector's port2, and the local port is connected to the connector'sport1. Processing ends at block 306.

Candidate ports must be identified to satisfy a requiresConnectionconstraint. FIG. 9B illustrates the CandidatePorts(list) process flow.Processing block 310 of CandidatePorts(list) set thePort variable to thenext port in the list. At decision block 312 (i.e., “is the portconnected?”), if the port is connected, processing continues atprocessing block 316. If not, decision block 314 (i.e., “thePort theright datatype or are conversions allowed?”) determines if the datatypesare compatible.. If not, processing continues to block 310 and the nextport is found.

If they are compatible, thePort is added to the port list, andprocessing continues at block 310. If it is determined that thePort isalready connected at decision block 312, processing continues atprocessing block 316, and newPort is set to the port to which thePort isconnected. At block 320, a new port list is created for all ports towhich newPort transfers. At decision block 322 (i.e., “does newListcontain a port of the requesting component?”), if the newList containsone of the requesting component's ports, the connection is marked asalready being in existence at block 326 and processing returns at block328. If not, CandidatePorts(list) is invoked for the newList.

Configuration Engine

When the user has selected the components for the system to be modeled,the user requests the invocation of the configuration engine. Theconfigurator accesses the Product Base to identify the object class.After certain validation checks are successfully performed, theconfigurator instantiates (i.e., creates) a member of that class, calledan object instance. The configurator only instantiates those objectsrequired to configure the requested system.

The configuration engine processes component and resource requests inthe priority specified. As each request is processed, the existingconfiguration is modified by: (1) adding the requested component andother components required to support the component requested, or (2)identifying existing components and new components required to providethe requested resource. When a request is successfully processed, theconfiguration modifications are “committed,” and this configurationbecomes the input configuration in processing the next request.

FIG. 6 illustrates the Configuration Engine process flow. Processingblock 202 creates a prioritized list of requests. If it is determinedthat all of the requests have been processed at decision block 204(i.e., “all requests processed?”), processing ends at block 206. If not,the next request is selected at processing block 208.

The request type is determined at decision block 210 (i.e., “requesttype?”). If the request is a component request, processing continues atprocessing block 212. At block 212, the component requested isinstantiated and posted to the Modifications List, and processingcontinues at decision block 216. If the request is a resource request,the component that can supply this resource is identified at processingblock 214 (i.e., “SatisfyResourceRequest”), and processing continues atdecision block 216. At decision block 216 (i.e., Instantiation orallocation successful?”), if the component instantiation or resourceallocation is successful, processing continues at decision block 224(i.e., “any constraints to be processed?”). If the componentinstantiation or resource allocation is not successful, processingcontinues at decision block 218 (i.e., “do any other alternatives existto satisfy this request?”).

If it is determined at decision block 218 (i.e., “do any otheralternatives exist to satisfy this request?”) that no other alternativesexist to satisfy the request, the request is identified as a failedrequest, and processing continues at decision block 204 (i.e., allrequests processed?”). If there are other alternatives, the failedalternative's modifications are removed from the Modifications List at220, the next alternative is posted to the Modifications List at 222,and processing continues at decision block 224 (i.e., “any constraintsto be processed?”).

At decision block 224 (i.e., “any constraints to be processed?”), ifthere are no constraints to be processed, the modifications arecommitted to the configuration at processing block 244, and processingcontinues at decision block 204 (i.e., “all requests processed?”). Ifthere are constraints to be processed, the next constraint is identifiedat block 226. If it is determined that it is a requiresContainerconstraint at decision block 228 (i.e., “requiresContainer?”),processing continues at processing block 230 (i.e.,“satisfyContainerConstraint”) to satisfy the requiresContainerconstraint, and processing continues at decision block 240 (i.e.,“constraint satisfied?”). If it is determined that it is not arequiresContainer constraint at decision block 228 but it is determinedthat it is a requiresConnection constraint at decision block 236 (i.e.,“requiresConnection?”), processing continues at processing block 232(i.e., “satisfyConnectionConstraint”) to satisfy the requiresConnectionconstraint, and processing continues at decision block 240 (i.e.,“constraint satisfied?”).

If it is not a requiresContainer constraint at decision block 228 andnot a requiresConnection constraint at decision block 236 (i.e.,“requiresConnection?”), processing continues at decision block 238(i.e., requiresComponent?”). If it is determined that it is arequiresComponent constraint at decision block 238 (i.e.,“requiresComponent?”), processing continues at processing block 234(i.e., “satisfyComponentConstraint”) to satisfy the requiresComponentconstraint, and processing continues at decision block 240 (i.e.,“constraint satisfied?”). At decision block 240 (i.e., “constraintsatisfied?”), if the constraint was satisfied, processing continues atdecision block 224 (i.e., “any constraints to be processed?”). If theconstraint was not satisfied, processing continues at decision block 218(i.e., “do any other alternatives exist to satisfy the request?”).

The fact that resources are offered by individual component instances,and are not represented as global system entities, assists in theexploration of alternatives. FIG. 7 illustrates theSatisfyResourceRequest process flow. At processing block 250, the nextcomponent that offers the required resource is found. If, at decisionblock 252 (i.e., “any component instances found?”), it is determinedthat no component offers the resource, processing continues atprocessing block 262.

If a component is found, processing continues at decision block 254(i.e., “has this resource been consumed?”). If the resource has beenconsumed processing continues at processing block 250 (i.e., “Find nextcomponent that offers the required resource”). If the resource has notbeen consumed, a check is made to determine whether class requirementsand optional requirements are valid at decision block 256. If all of thechecks are valid, the current resource instance is chosen at processingblock 258, and processing continues at processing block 264. If one ofthe checks is invalid, processing continues at decision block 260 (i.e.,“have all resource instances been checked?”). If all of the resourceinstances have not be checked, processing continues at block 250 wherethe next component offering the resource is found.

If all of the components offering this resource have been checked, or itis determined (at decision block 252) that no existing component offersthis resource, processing continues at block 262, and a new componentinstance that offers the resource is created, the configurationmodification is posted to the Modifications List, and processingcontinues at block 264. At block 264, an instance of the requestedcomponent type is assigned to the requesting component's returnedinstance variable. Processing continues at decision block 266 (i.e.,“does the current instance satisfy query and test conditions?”) todetermine if all query and test functions are satisfied. If not,processing continues to processing block 250. If they are, processingends at block 268.

Model Language

The model language provides the ability to define a model (e.g., modelelements, model constraints, and model structure). Using the syntax ofthe model language, statements may be entered to define the model base,or Product Base. The Product Base contains all of the information abouta model. The Product Base contains the information used to configure asystem.

The Product Base may also contain Hierarchical Product Lines. ProductLines allow a Product Base to be subdivided into groups. An example ofsuch a grouping is marketing divisions, such as DesktopSystems. ADesktopSystem might contain all of the components that are commonly soldas parts of a desktop computer system such as operating system software,modem cards, microprocessor chips, etc. Only components that are part ofthe same product line can be configured together. However, eachcomponent type can be part of several product lines. Product Lineshierarchies may also be declared. A child in a product line hierarchyinherits from the parent, and every component in the parent is inheritedby the child. The format of a product line declaration is as follows(Note: reserved words are bold, double-underscores indicate repetitiveportions, and portions contained in “<<>>” are required):

-   -   productLine <<ProductLineName>>;        Or, to declare product line hierarchies:    -   productLine <<ProductLineName1>>: <<ProductLineName2>>;

System models are stored in files, called parse files. Collectively, theparse files are known as the Product Base. Parse files containinformation about a general category within a system model. Datarepresentations of individual system parts are known as objects.Cabinets, storage devices and peripheral cards are examples of objectsin a Product Base used to configure computer systems. A propertyprovides attributes of an object. For example, in a computer systems'Product Base, capacity, power requirements, and connection interface areproperties of a storage device object. Further, a property categorizesan object. That is, objects with similar properties are called a classof objects. Objects can inherit properties from other objects. That is,one class of objects acts as the parent of another class, and the childclass exhibits all of the properties of the parent class in addition toothers.

Attributes define the aspects of a component that must be considered tosuccessfully configure a component. Examples of attributes of a powersupply are the cabinet space required for the supply and the remainingpower available after power-consuming components are added to theconfiguration. Attributes can be assigned at the class level, anddescendants of that class inherit the class attributes. In addition,attributes can be associated with particular component types. There isno limit to the number of attributes that can be assigned to a componentor class.

Attribute values may be of type floating point, boolean, string,datatype, component, and resource. Attributes may be multivalued. Thatis, multivalued attributes can have more than one value. For example,with a component that can use either a full height internal bay or afront accessible bay, the attribute “attribute_Bay_type_required” canretain both values. An attribute is declared by the statement (Note: “|”indicates a choice):

-   -   AttributeType <<Attribute Name>>; |    -   Multivalued AttributeType <<AttributeName>>;

An example of attribute declarations are: Float Position Floatthroughput_available Float load_consumed resource space_type_required

A resource is a system commodity that is associated with componenttypes. A resource may be assigned to multiple component types. Multipleresources may be assigned to a component. When a component isinstantiated, the resource assigned to this component type is madeavailable to the configuration. When a component's resource is consumed,only the resource supplied by its associated component becomesunavailable. The availability of a resource of the same type that isoffered by a second component is unaffected by the consumption of thefirst component's resource. Therefore, if the same resource type isavailable from a second component, the consumption of the firstcomponent's resource does not consume all of this resource type in themodeled system.

Before a resource type can be assigned to a component type or used by acomponent instance, the resource type must be declared. A resourcedeclaration has the following format:

-   -   resource <<ResourceName>>;        An example of a resource declaration is as follows:    -   resource static_RAM_resource;

Datatype declarations define the types of interfaces and data transferprotocols available to connections in a modeled system. SCSI and IDE areexamples of datatypes. A datatype is declared as follows:

-   -   dataType <DataTypeName>>;

A derived class is defined by the following statement (Note: the portionwith the “

” symbol is optional): Class <<ClassName>>: <<BaseClassName |SuperClassName>> { displayStatus: <<HIDDEN | LISTED | DRAWN>>

attributes: <<AttributeName = AttributeValue;>>

dimensions [Xsize, Ysize];

connectionOrigin <<TRUE | FALSE>>;

}

The display status includes the values Hidden, Listed, and Drawn. Drawnallows the class member to be displayed in the graphical rendering ofthe configuration. Listed allows the class members to be listed on theadditional components list. Hidden is used for members that are Hidden(i.e., not drawn), but have children that are Drawn. An attribute valuemay be assigned at the time of declaration, but this is not necessary.Connection origin identifies whether or not instances of this class areto be used as starting points for cabling report generation. An exampleof a derived class declaration is as follows: class Bay: Container {displayStatus: DRAWN; attributes:   front_accessible;   height;  half_height_compatible;   position; }

In this example a derived class, bay, is created. It is a member of theContainer base class. Therefore, it may contain other elements. Itsattributes define its height, half_height compatibility,front_accessibility (i.e., is a component installed in this bayaccessible from the front of a system cabinet), height, and position.These attributes will be inherited by each descendant of this derivedclass.

System components, or component types, are defined by the followingdeclaration: component <<ComponentTypeName>>: <<DerivedClassName>> {

productLines: <<ProductLineName;>>

label: <<“LabelName”;>>

description: <<“DescriptionString”;>>

resource: <<ResourceName

, IntegerValue

;>>

dataType: <<DataTypeName;>>

partNum: <<“PartNumString”;>>

subComponents: <<SubcomponentName;>> V      <<SubcomponentName{Integer};>>

transfers: <<SubcomponentName[0] <-> SubcomponentName[1];>>

dimensions: [<<Xsize, Ysize>>];

values: <<AttributeName = AttributeValue;;>> V     <<AttributeName ={AttributeValue,...};>>

fillDirection: [ <<TB | BT | LR | RL>> ];

}

The label field defines the label given to the graphical representationof this component. The description field defines the description that isdisplayed or reported. The dataType field is used if the component typeis descended from a port, and defines the type of data that may betransferred from this component type. The subComponents field definesthe structural children of a Composite component type. The transfersfield defines the paths that data can travel through a Compositecomponent. Transfers are a mechanism for expressing an internal datapath within a Composite component. For example, a cable is representedas a component with two ports, and the cable is used to transfer datafrom one port to another. The values field provides the ability toestablish a component's attributes, or properties. The fillDirectiondescribes the order in which multiple components in a single containerare drawn.

The following is an example of a component definition: ComponentCabinet1 : Cabinet { partNum: “001-001”; Children: Slot1_1; Slot1_2;Slot1_3;   ... Slot1_9; Slot1_10; CabinetBay {4}; Values: position = 1;resources_provided = {10_Slot_Resource, CPU_Slot_Resource,MCU_Slot_Resource, Mem_Slot_Resource, Bay_Resource}; }

This example defines a component type, Cabinet1, within Cabinet andComposite classes. FIG. 4 is the structural hierarchy for a model usedto configure computer systems. Cabinet1 108 is descended from Cabinet110 which is a descendant of Composite 112. Therefore, Cabinet1 108 is acomposite component type. It has subcomponents, or children, Slot1_1through Slot1_10 and CabinentBay{4}). The integer “4” indicates thatthere are four CabinetBay component types within Cabinet1.

The following is an example of a Composite component type that descendsfrom a connector: Component SCSIChainCable: Cable { description: “SCSIChain Cable”; partNum: “003-002”; subComponents:   SCSICablePort_3;  SCSICablePort_4; values:   length = 2; transfers:   SCSICablePort_3<-> SCSICablePort_4; }

The following is an example of a component type definition that providesa resource: Component 16mbMemCard : Card { description: “16mb MemoryCard”; partNum: “004-016”; resource: Memory_Resource, 16; values:  slot_resource_required = Mem_Slot_Resource; }

Constraints provide conflict resolution information used to determinewhether components may be added to the configured system. Constraintscan control such things as space allocation, space occlusion, andadditional component requirements. Constraints are expressed ascomponent qualifiers and component dependencies. Constraints test theattributes and lineage of components and identify the components thatare required for the successful instantiation of components. constraint<<ConstraintName>> on <<ClassName>> { <<requiresComponent |requiresContainer>>  (<<ClassName, ResourceName | ClassName |ComponentName>>, <<?ReturnedInstance>>

, ?ReturnedInstance.AttributeName

, Consumed

, Existing

, New

); } constraint <<ConstraintName>> on <<ClassName>> {<<requiresConnection (

StartingComponentName,

<<ClassName, ResourceName | ClassName | ComponentName>>, <<DataType>>,<<?ReturnedInstance>>, <<%Path>>

,?ReturnedInstance.AttributeName

, Connector ( <<ClassName>>, <<?ConnectorInstance>>,     <<?ConnectorInstance.AttributeName>>)

, Longest

, Consumed

, Existing

, New

, Conversions

); }

The Constraint Name and the Class upon which the constraint may beapplied are identified in the first line of the declaration. TherequiresComponent, requiresContainer and requiresConnection expressionidentifies additional items (i.e., components, container, orconnections) that are required to configure the constrained component.The additional items needed may be identified by a derived class nameand resource combination, a derived class name, or the name of thecomponent type. When a request is satisfied during configuration, theconfiguration engine returns the instance of the requested componenttype found. The ?ReturnedInstance variable identifies the variable thatis associated to the instance of the requested component type found bythe configuration engine. A request may further ask that theconfiguration engine make a choice based on attribute maximization. Thatis, make a choice that will maximize a given attribute. Therefore, a?ReturnedInstance.AttributeName declaration will return the requesteditem with the greatest amount of AttributeName. The attributemaximization option can also be an expression that refers to otherreturned instances created by previous component requests with thecurrent constraint and perform operations with them. A componentinstance is said to be consumed when it is unavailable to satisfy aconstraint requirement. The Consumed keyword can be used to mark aninstance returned by a request as unavailable. Once an instance isconsumed, the configuration engine will exclude this instance insubsequent searches to satisfy another request. The Existing keywordlimits the search to existing instances. The New keyword requests that anew instance be created to satisfy a constraint requirement.

The requiresConnection constraint requirement has additional argumentsthat describe the requirements for an entire connection path that cancontain several different components. The requiresConnection constraintrequirement has one requirement that is additional to and different fromthe requiresComponent and requiresContainer constraints. Like the othertwo constraint requirements, the requiresConnection requires that therequest be satisfied. In addition, the requiresConnection constraintrequirement, requires that the constrained instance be connected to thesatisfying instance.

The StartingComponentName field, or variable, refers to the startingcomponent in the connection (i.e., where the connection will begin). Ifthis variable is not set, the starting component is assumed to be theconstrained instance. The next line (i.e., “<<ClassName,ResourceName|ClassName|ComponentName>>”) identifies the connectioncomponent.

The type of data that the connection will carry is specified by theDataType field. The dataType field specifies the data type requirementsof a port of the requested instance. Further, the dataType fieldspecifies the data type requirements of a port of the constrainedinstance. Because the dataType field only requires that the constrainedinstance's port and the requested instance's port be of data typedataType, a connection constraint can be satisfied by a multiple stageconnection. For example, it is possible to connect a SCSI device to aSCSI card through intervening components.

FIG. 5 illustrates component interconnections with multiple interveningcomponents and data types. ConstrainedInstance 161 has port 160 and port162. Port 162 is connected to Connector 179 at Port 163. Port 164 ofConnector Block 179 is connected to Port 165 ofFirstInterveningComponent 166. Port 167 of FirstInterveningComponent isconnected to Port 168 of Connector 180. MultipleInterveningComponents183 represents some number of intervening components that may be placedbetween FirstInterveningComponent 166 and NthInterveningComponent 173.Connector 180 and Connector 181 are positioned on either end of theMultipleInterveningComponents 183. Port 171 of Connector 181 isconnected Port 172 of NthInterveningComponent 173. Port 174 is connectedto Port 175 of Connector 182. Port 176 of Connector 182 is connected toPort 177 of DiskDriveController 178. Chain 184 represents the chainedcommunication or connection path between ConstrainedInstance 161 andDiskDriveController 178.

The ?ReturnedInstance and ?ReturnedInstance.AttributeName fields havethe same functionality as in the requiresComponent and requiresContainerconstraint expression. The %Path variable is bound to all of theinstances used to make the connection. That is, all of the instancesinvolved in a connection are referred to as the connection path.

With respect to the ?ReturnedInstance.AttributeName and the?ReturnedInstance instance variables, the maximization option is thesame as for the requiresComponent and requiresContainer constraints.There are two maximization options for the path instance variable. Thefirst option is the connector the option. The ClassName field specifiesthe desired class of connector instances used to build the path. The?ConnectorInstance field is bound to the returned connector instance,and the AttributeName is the connector instance attribute to bemaximized. The request for ?ConnectorInstance is maximized in the sameway as the returned instances for requiresComponent andrequiresContainer.

The second maximization option provided by requiresConnection is thepath length option. This option provides the ability to prioritizechoices among paths from the requested component to the requestingcomponent. The length of a path is defined as the number of componentinstances in the path, including instances of class Connector. Thelongest path may be specified by using the “Longest” keyword in theconstraint declaration. If the longest path option is not chosen, theconfiguration engine selects the shortest path.

The Consumed, Existing and New specifications of the requiredConnectionconstraint have the same functionality as in the requiresComponent andrequiresContainer constraint declarations. The Conversions optionprovides the ability to specify that the requested instance can have adatatype that is dissimilar to the constrained instance. That is, ifthis option is chosen, the requested-side port is no longer required tocarry data of type DataType. The only requirement is that the datatypespecified by the dataType variable be available at the requester-sideport. This option expands the alternatives that the configuration engineis allowed to consider in satisfying the connection request, since itdoes not have to choose the terminal component with the same datatype asthe requester instance. Therefore, if a connection constraint allowsconversions, satisfaction of a request for a SCSI connection need onlydeliver SCSI data to the requesting instance.

The following is an example of a constraint definition: constraintStorage_device_constraint on StorageDevice { requiresConnection(SCSICard, SCSIDatatype, ?card, %path,   Connector (Cable, ?c,-?c.length, Longest)); requiresContainer (Bay, Bay_Resource,?bay.Consumed);         *         *         * }

The requiresContainer constraint indicates that the StorageDevicecomponent type requires a container (i.e., a bay). In addition, thisconstraint definition imposes a constraint on the StorageDevice class ofthe model hierarchy and all of its descendants. It requires the longestcable component type connection to a SCSICard component type. The typeof data that will be carried by this connection is of datatypeSCSIDatatype. A port of the constrained instance must also be of thisdatatype. The datatype constraints may be fulfilled with a multiplestage connection. Thus, the SCSI StorageDevice may be connected to theSCSICard through intervening components. The variable ?card identifiesthe SCSICard instance used. The %path variable contains informationregarding the instances used to make the connection.

The model language provides the ability to perform further tests andqueries to ensure that the configuration engine returns usable instancesor instance sets. If a constraint contains a component request, thesequeries and tests are placed after that request. If the queries andtests are not satisfied, the configuration engine continues to searchfor another alternative to satisfy the request. The following areexamples of the tests provided in the model language: mathematicaloperators: + (addition) − (subtraction) * (multiplication) / (division)ABS (absolute value) SQRT (square root) relational operators: > (greaterthan) < (less than) == (equality) >= (greater than or equal to) <= (lessthan or equal to) != (not equal) boolean operators: OR (logicalinclusive or) AND (logical conjunction) NOT (logical negation)assignment operator: := (becomes; takes the value of)

For example, in configuring a computer system, a test may be performedwhen configuring a floppy disk drive for the computer system. A floppydisk drive requires a bay or slot within the system cabinet. Such aconstraint would be expressed as a requiresContainer component request.This request would cause the configuration engine to search for acandidate instance to satisfy this request. Once the engine returns thecandidate instance (i.e., ?bay), further testing can be done todetermine whether the drive will fit in the returned instance. This canbe tested by comparing the height attribute values of the candidateinstance (i.e., ?bay) and the constrained instance (i.e., ?this) asfollows:

-   -   ?bay.height>=?this.height

Intrinsic functions provide additional capability to perform tests andqueries. Intrinsic functions can be grouped into query functions andpredicate functions. The following are examples of query functions:

-   -   ceil Queries an attribute of type float, or any expression that        evaluates to a floating point value, for the smallest integer        value greater than or equal to the floating point value.        -   Returns an integer.        -   Syntax: ceil (<<Expression>>)    -   ClassName Queries a set variable for all instances in the set        that belong to the specified class.        -   Syntax: ClassName (<<%InstanceSet>>)    -   ComponentName Queries a set variable for all instances in the        set that belong to the specified component type (i.e., leaf        class).        -   Syntax: ComponentName        -   (<<%ReturnedInstance>>)    -   Component Queries a set variable for all instances that are not        descended from class Connector.        -   Syntax: Component (<<%InstanceSet>>)    -   component Queries an instance for the component type (i.e.,        class hierarchy leaf class) from which it is descended. Returns        the parent component type.        -   Syntax: component (<<%ReturnedInstance>>)    -   COUNT Queries a set variable for all instances in the set that        belong to the specified class.        -   Syntax: COUNT (<<ClassName|ComponentTypeName>>            <<(%InstanceSet)>>)

The following is an example of a constraint definition using query andpredicate functionality: constraint Storage_device_constraint onStorage_Device { requiresConnection (SCSICard, SCSIDatatype, ?card,%path,   Connector (Cable, ?c, -?c.length, Longest); requiresContainer(Bay, Bay_Resource, ?bay, Consumed); ancestor (?bay, Cabinet) ==ancestor (?card, Cabinet); FORALL (?inst1, Storage_Device(CONNECTS(FIRST(%path))));   ancestor (?inst1, Cabinet) == ancestor(?this, Cabinet)); }

In this example, Storage_Device requires a connection to a component oftype SCSICard. The connection must be of datatype SCSIDatatype. Thecomponent instance of type SCSICard is bound to the instance variable?card, and the components in the connection path are bound (as a set) tothe set variable %path. The connector component used to complete theconnection must be of type Cable, and is bound to the instance variable?c. Candidate cables are ordered from shortest to longest, and ifalternative paths from the SCSICard instance exist, the longest path (interms of number of components) is preferred.

This example further indicates that Storage_Device must be placed in acontainer component of type Bay. This instance of type Bay must supplyBay_Resource. The instance of Bay is bound to instance variable ?bay,and the instance is marked as comsumed (i.e., unavailable in subsequentrequests for compoents of type Bay).

In the example, the phrase “ancestor (?bay, Cabinet)==ancestor (?card,Cabinet” requires that the structural ancestor (of type Cabinet) of theinstance identified by ?bay must be the same instance as the structuralancestor (of type Cabinet) of the instance indentified by ?card. Inother words, the card and the bay must be in the same cabinet.

The “Forall” phrase used in the previous example indicates that allcomponent instances of type Storage_Device connected to the first cablein %path must be in the same cabinet as the constrained instance ofStorage_Device.

Constraint relationships may be established either at the componentlevel or at the class level. At the component level, constraintrelationships specify which component types are constrained by whatconstraints. The component designated in the constraint relationship maybe any of the component types that have been defined by a Component Typedeclaration. The constraint may be a constraint declared by a Constraintdeclaration. The following is the syntax for specifying a componentlevel constraint: <<ComponentTypeName>> constrainedBy<<ConstraintName1>>

<<OR | AND>> <<ConstraintName2>>

, <<OR | AND>> <<ConstraintNameN>>

;

Constraints may also be expressed at the class level. A class-levelconstraint is evaluated as a conjunct in component-level constraintexpressions for all component types derived from the constrained class.When a component-level constraint expression is evaluated, class-levelconstraints are appended to the beginning of the constraint expressionand end with that constraint's request and predicate functionexpressions. If a component inherits class level constraints fromseveral levels in the Class Hierarchy, the constraints are ordered fromthe most primitive class (i.e., the root class Component) to the mostsystem-specific class(i.e., the user-defined component type). The syntaxfor a class-level constraint relationship declaration is as follows:

-   -   constrain class <<ClassName>> with <<ConstraintName>>

The present invention provides the ability to represent within astructural hierarchy how components of a particular system existspatially and physically using three type of substructures: compositehierarchies, container hierarchies, and connection relationships.Composite hierarchies identify components as part of other components.Container hierarchies identify components as being contained in othercomponents. Connection relationships identify components that connect toother components. The relationships between generations within thestructural hierarchy are expressed by the keywords “childOf,”“containedBy,” and “connectsWith. Structural relationships are declaredas follows: <<ClassName>> childOf <<ClassName>> <<ClassName>>containedBy <<ClassName>> <<ClassName>> connectsWith <<ClassName>>Model Maintenance

A model can be defined by providing statements that syntacticallyconform to the model language described above. In addition, aninteractive facility, the Model Maintenance Subsystem, provides theability to define, and maintain a model, using a graphical userinterface. The Model Maintenance Subsystem provides the ability tointeractively define the Product Base using a graphical user interface.The semantic representations, class hierarchies, and structuralhierarchies of the model may be viewed (i.e., browsed) and modified(i.e., edited) interactively using a graphical user interface. Further,constraint input is verified. Testing and debugging capabilities areprovided to identify problems in the model, and to test and optimize theperformance of the modified model. For example, model definition syntaxis parsed and verified, and sample requests may be executed. Diagnosticsfunctions may be invoked to monitor the performance of the configurationrequests with the modified model.

The browsing capability of the maintenance system provides the abilityto view graphic representations of the class and substructuralcomponents of the model hierarchy. A Class Tree is used to representobjects descending from base classes within the model hierarchy (i.e.,an object class hierarchy). The object class hierarchy is represented byfive separate trees, one for each base class. Each branch may havemultiple descendants.

A Component Tree is used to depict the Composite, Connector andContainer Component substructural interrelationships. Composite Treesare listed first followed by Connector and Container Trees.

A hierarchy member may be selected for modification by double-clickingon the box that contains the hierarchy member. An editor window for theselected hierarchy member is displayed. A List menu may also be used toselect the member to be edited. In the preferred embodiment, the Listmenus are a series of pulldown menus that may be selected from a menubar of the Maintenance window. The initial menu bar contains a selectionfor each general element of the ProductBase model (i.e., classes,component types, constraints, etc.). Once a general element is chosen, anew window is displayed that lists the model members of the general typeselection. A model member may be chosen along with an operation (i.e.,Comment, View, New, or Edit). A Comment operation provides the abilityto add a comment to the ProductBase after the selected member. A Viewoperation provides the ability to view the settings for the selectedmodel element. The model member may be modified by choosing either a Newor Edit operation.

For example, to modify an attribute of a model member in the preferredembodiment, the attribute type is chosen from the List Menu. Once theattributes are displayed, a New or Edit operation may be chosen to add anew attribute, or modify an existing attribute, respectively. Anattribute selection must also be made, if the Edit operation is chosen.After these selections have been made, the Attribute Editor window isdisplayed. The fields of the window (e.g., name, attribute type, andmultivalued) are initialized to either blank or the default settings fora New operation, or initialized to the current attribute settings for anEdit operation. The attribute name field may be selected and modified.The type field may be modified by selecting from a list of validattribute types. The multivalued field may be toggled on or off. Aftermaking modifications, the modifications may be saved or cancelled.

Resources and Datatypes may be added or modified in a manner that issimilar to the method for adding or modifying an attribute. Modelelements that require relational definitions require additionaldesignations. Examples of these are derived classes, product lines(i.e., parent Product Line), constraints (i.e., constrained class), andcomponent types.

In the preferred embodiment, adding a derived class requires anadditional initial step to define the location of the new derived classwithin the model hierarchy. At this point, the New and Edit operationshave the same operational characteristics, including the ability to saveor cancel. That is, the derived class field values (existing, default,or blank) are displayed in an Editor window. In addition, attributes maybe added to all members of the derived classes and their componenttypes; constraints may be specified at the class level for the derivedclass; structural hierarchy relationships may be defined for the derivedclass; the System Window display status may be defined; the derivedclass may be selected as a connection origin (i.e., a starting point ofa cabling report); and the component distance (i.e., the averagedistance from members of the derived class to other objects that are apart of the same composite, and the distance from the member of thederived class to an external port on the composite) may be defined forchildren of composite objects that are involved in connections.

To add a new component to the model, the class from which the new classis descended must be chosen. The subcomponent field provides the abilityto specify the structural hierarchy (i.e., structural children) of acomposite component. The New or Edit operations further provide theability to specify connectivity fields such as transfers (i.e., pathsthat data can travel through a Composite component), datatype,connection origin. In addition, the following field information may bespecified: component type name, associated attributes, products lines(i.e., product lines that contain this component), leaf-levelconstraints, resources, description, label, part number, fill direction,and display status.

The Maintenance system further provides the capability to test amodified model. The Write integrity option determines whether aParseFile (i.e., ) can be parsed, and a modified ParseFile written. TheProductBase Integrity option determines whether a ParseFile (i.e., ) canbe parsed, and a modified ParseFile written. If not, syntax errormessages are displayed. The Debugger (i.e., Configure) option readscomponent requests from a request file and attempts to configure thosecomponents using selected constraints in the current ParseFile. TheDebugger provides a tracer capability to provide constraint tracing. Adeep trace generates trace output for a traced constraint and all theconstraints it spawns. A shallow trace generates a trace output fortraced constraints.

Needs Analysis

The process of translating customer requirements into specificcomponents and configurations is called “Needs Analysis.” The modellanguage provides the ability to express a model in terms of customerneeds and requirements.

With a needs analysis approach to modeling, a configuration may also beexpressed in terms of capacities (e.g., minimum required response time)or throughput. The needs analysis configuration may be illustrated by avoice messaging system model. A configured voice messaging system may berequired to record some specific number of hours of voice data, andprovide a response time of less than five seconds for accessing storedmessages. To further illustrate, a telecommunications configuration maybe specified in terms of traffic load supported and some maximumacceptable failure rte (e.g., dropped calls), or a computer systemconfiguration may be required to support certain processing loads, datastorage requirements, and response times.

The model language provides the capability to express a needs analysismodel in the configuration modeling language by: (1) interpretingcustomer requirement quantities (e.g., voice message storage capacity),and (2) identifying associated quantities of configuration componentsand resources. This provides the ability to make modeling requests interms of needs in addition to component requests. Components can beidentified as satisfying requirements or needs. That is, components maybe identified as supplying some quantity of a resource (e.g., megabytesof storage capacity). When a user expresses a system, or some portion ofa system, in terms of needs or requirements, one or more components thatsatisfy the needs may be selected from the ProductBase.

Input Forms

Input forms provide the capability to accept component requests from theuser. Input forms allow the user to specify the types and quantities ofcomponents in the system to be configured. Input forms consist ofstandard windowing formats such as listboxes and pushbuttons. A thirdtype of input form provides the ability to specify a quantity of a givencomponent (Note: documentation says this is unique . . . do we need moreabout this feature for this application?) The user selections on theinput forms are called component requests. Input forms provide theability to associate a default priority for component requests. Defaultpriorities may be overridden by a requestPriority. These prioritiesprovide the ability to designate the order in which component requestsare satisfied by the configuration engine.

Product-Component Mapping

Product_component mapping defines discrete and composite components asparts and products in a sales inventory, and then maps those parts andproducts (i.e., bundles) onto a set of all component instances in aconfigured system. The product-component map contains representationsthat define each part and product in terms of its required and optionalconstituent components. These representations further specify how theproducts are displayed by the Quoter. A representation is comprised of athe following sections: a Product Header, an Optional Equipment List,and an Option Restriction List.

The Product Header section provides the product name as it appears inthe ProductBase. This allows the Bundler to match components in aconfigured system to products and identify a set cover. This sectionalso includes the following additional information: a ProductDescription String that describes the product for use by other portionsof this invention (e.g., the Quoter); a Product Number String; the Price(i.e., the price of the product); Product Lines String identifies theproduct lines of which the product is a member, and is used to narrowthe set covering search; and a Required Components List that identifiescomponents (i.e., by part number) or products (i.e., by product number)that are required by this product.

The Optional Equipment List is a list of additional product packagesthat can be included in the base package (i.e., the product described inthe Product Header). An Optional Equipment List entry contains: anOption Unique ID to uniquely identify the entry; an Option Descriptionthat describes the entry; an Additional Cost to identify an additionalcost associated with the inclusion of this entry; and a ConstituentProduct Number List identifies those products or components, by number,that comprise the entry.

The Option Restriction List is a list of groups of options that areinterdependent or that must be chosen according to special criteria.Each entry in the Option Restriction List contains the following: aGroup Unique ID to uniquely identify the entry, a Quantity Specifier,and an Option Unique ID List. The Quantity Specifier field specifies thenumber of members of an option group that may or must be chosen. TheQuantifier Specifier field may consist of bounds or the atLeastOne,atMostOne, or exactlyOne keywords. The bounds are two integers (enclosedin parentheses and separated by a comma) that express the lower andupper bound. The atLeastOne keyword indicates that one member of theoption group must be chosen. The atMostOne keyword indicates that onlyone member of the option group may be chosen, and that it is notrequired that any member be chosen. The exactlyOne keyword indicatesthat at least one member of the option group must be chosen, but no morethan one. The Option Unique ID List is a space-separated list of OptionUnique ID's.

An example of an entry in a product-component map for a modelconfiguring computer systems is as follows: product base_system {description: “Base System”; productNumber: “001-001”; cost: 10000;values:   category1 = “System”;   category2 = “XXX”; productLines:Tower; required: (“001-001” reference) “002-001” “002-002”; options:  COM1 “Comm Option 1” 1 “002-005”;   COM2 “Comm Option 2” 1 “002-006”;optionGroups:   g1 atMostOne Com1 Com2; }Bundler

The Bundler bundles components into product (i.e., marketing) packages.The Bundler uses the product-component map to establish a set cover fora configured system. A set cover is a set of many-to-one mappings ofcomponent instances in a configured system to product packages in whicheach component instance is mapped to one product package.

Set covering is the process of covering a set of objects (e.g.,component instances in a configuration) with a set of covers (e.g.,products). This process is used to associate components created for thecurrent configuration with some grouping or cover (e.g., products). Acommon problem associated with the set covering process is that as thenumber of objects and set cover alternatives increase, the number of setcovering alternatives explodes exponentially. To limit the set coveringalternatives, heuristics may be used to identify the mininmum set ofcovers. The Lowest Cost Cover is an example, of a heuristic. Using thisheuristic, covering is maximized and cost is minimized. That is, theproducts providing the most cover for the least amount of cost areselected.

Another heuristic is based on the structural context of thealternatives. That is, in some instances, a product will have structure,and that structure will define a physical unit or grouping ofcomponents. This may occur, for instance, when a reduction inmanufacturing cost is incurred when components are produced as a unit.This savings may be passed on to the purchaser of a system where thereduced-cost unit is actually being purchased. Therefore, it isnecessary to examine the configured components to determine theirstructure context, and then match these attributes with the structurecontext of the products. An example of this is a disk array in acomputer configuration model. The disk array is physically configured,or manufactured, with a chassis, power supply, controller and five diskdrives. Therefore, it is necessary to examine the structure context ofany disk drive component requests. The process of selecting instances as“covered” by the disk array product must include a determination thatthe “covered” instances were configured to be inside the chassis, or asa disk array unit.

FIG. 10 illustrates the EstablishSetCover process flow. At processingblock 450, the products that can cover some or all of the componentinstances in the current configuration are identified. At decision block452 (i.e., “any products identified?”), if no products have beenidentified, processing ends at block 454. If products were identified,the products are prioritized based on the number of instances that canbe covered by the product at processing block 456. At decision block 458(i.e., “any instances not covered?”), if all of the instances have beenmapped to the current prioritized product list, a new product list iscreated that covers products in the current configuration at block 474,and processing continues at decision block 452 (i.e., “any productsidentified?”).

If not, the next product is selected from the list at block 460. Atdecision block 462 (i.e., “do all required elements exist?”), if all ofthe elements of the product do not exist in the configured system,processing continues at processing block 460. If they do exist, theinstances that have not been previously mapped and that can be coveredby the current product are identified at processing block 464. Atdecision block 466 (i.e., “any instances identified?”), if no instancescan be covered by the product processing continues at decision block 458(i.e., “any instances not covered?”).

If some instances were identified, it is determined whether any productoption restrictions can not be met at decision block 468 (i.e., “anyproduct option restrictions that are not met?”). If there are,processing continues at decision block 458 (i.e., “any instances notcovered?”). If not, processing continues at decision block 470 (i.e.,“all structural contexts satisfied?”). If, they are not, processingcontinues at block 460 and the next product is obtained. If they are,the mapped component instances are marked as covered by the currentproduct at block 472 and processing continues at decision block 458(i.e., “any instances not covered?”).

Representation of Modeled System

Once a system has been configured based on the requests made, variousreporting tools are employed to provide information regarding theconfigured system. In the preferred embodiment, these tools include agraphical depiction of the general layout of the system, a list ofmaterials, a list of spare parts, and a list of any component requeststhat could not be satisfied.

The present invention provides the ability to express a model instructural terms. That is, components are defined in terms of theirstructural parents (i.e., containers), interconnections, andcompositions. Therefore, the present invention has the ability tographically display the configured system along with its structuralcharacteristics.

The graphical depiction of the configured system and its structuralcharacteristics, called the system window, provides a depiction of thegeneral layout of the configured system. In the preferred embodiment,the system window for a model that configures computer systems shows theinterior and front of all cabinets used in the system, and shows theplacement of cards, power supplies, and storage devices. FIG. 11illustrates a system window for a desktop computer system configuration.System Window 540 illustrates the configured system's components andtheir relative locations within the system. Chassis 550 contains SystemBoard 552, DriveCage 554 and Power Supply 556. Main Board 552A is adetailed depiction of System Board 552.

Main Board 552A illustrates the physical placement of other componentson the system board and their relative positions. For example, EVGAVideo Board 558 is located below CPU Board 560. Further, the placementof Network Card 562 and FAST SCSI 564 in slots relative to CPU Board 560can be determined from System Window 540. Free slots 566 can be viewedas being open and the closest slots to CPU Board 560. Memory ExpansionBoard 568A is a detailed depiction of Memory Expansion Card 568. 1M Simmchips 570 are located on Memory Expansion Board 568A. Eight memory banks572 remain unused. Drive Cage (Side View) 554A is a detailed depictionof the Drive Cage 554. 535 MB Hard Drive (SCSI) 574, 3.5″ 1.44 MB FD)576, and a 525 MB Tape Backup (SCSI) 578 are contained within the DriveCage 554. Front 580 indicates the location of the front side of DriveCage (Side View) 554A. Therefore, 3.5″ 1.44 MB FD 576 and 525 MB TapeBackup 578 have been configured to be front-accessible components. Bay582 is a front-accessible bay that does not contain any device. Bay 584is a free bay located in the back of the Drive Cage 554.

The system window further provides the ability to interactively edit thegraphically rendered structures. The present invention provides theability to modify the structural aspects of the configured system byadding, deleting or replacing components within a configured structure.The present invention further provides the ability to modify theconfigured structure by modifying the structural interconnections andcompositions.

This capability to graphically display and edit can be used on a newlyconfigured system, or an existing configuration, or system. That is, anyupgrades to an existing, configured system may be performed graphically.A “freeze and fill” capability allows the user to freeze some portion ofthe existing system, and fill, or modify the unfrozen portion. This“freeze and fill” capability further provides the ability to generate aquote for the new configuration that represents only those componentsadded to the original configuration, and that incorporate any credit forthe deleted or replaced components.

In the preferred embodiment, the list of materials, called the Bill ofMaterials (BOM) provides a list of all of the configured components andspare parts that are used in the system since the last request toconfigure the system. The part number and description is provided foreach component and spare part.

In the preferred embodiment, the parts list provides informationregarding additional components (i.e., spare parts), resource totals,failed requests, and failed optional requests. Resource totals providesa total of all components and resources requested directly from theuser. Failed Requests and Failed Optional Requests are those componentrequests that could not be satisfied because of a lack of space,connector availability, etc.

Quoter

The Quoter calculates the cost of the individual product packages anddetermines the cost of all product packages required to complete thesystem. The Quoter provides the ability to display the quote in variousways. For example, the quote may be displayed by product with thecapability to expand or collapse the product information to show pricingfor individual product parts or for the entire package, respectively.The way in which products are presented or prices are calculated may becustomized.

1. A method of configuring a system using a computer system comprisingthe steps of: defining in said computer system an element modelconsisting of elements used to configure said system and structuralrelationships between said elements in said model; generating by saidcomputer system a system configuration based on configuration requestsand said element model; and displaying by said computer system agraphical representation of said system configuration and saidstructural relationships between said elements of said systemconfiguration. 2-15. (canceled)